1. Statement of the Technical Field
The present invention relates to the field of network security and more particularly to the use of synchronization (SYN) cookies in a transmission control protocol three-way handshake.
2. Description of the Related Art
Internet security has increasingly become the focus of both corporate and home computer users who participate in globally accessible computer networks. In particular, with the availability and affordability of broadband Internet access, even within the home, many computers and small computer networks enjoy continuous access to the Internet. Notwithstanding, continuous, high-speed access is not without its price. Specifically, those computers and computer networks which heretofore had remained disconnected from the security risks of the Internet now have become the primary target of malicious Internet hackers, crackers and script kiddies, collectively referred to as “malicious hackers”.
Notably, many such unauthorized intruders continuously scan the Internet for Internet Protocol (IP) addresses and ports of vulnerable computers communicatively linked to the Internet. At the minimum, those vulnerable computers can experience nuisance damage such as accessed, deleted or modified files or defaced Web pages. Yet, at the other extreme, for the unsuspecting end-user their computer can become the staging area for “zombies” with which more malicious attacks can be launched resulting in the crippling of whole segments of the Internet.
Malicious hackers often exploit well-known characteristics of the Transport Control Protocol (TCP) in order to cause segments of the Internet to deny service to other, legitimate users of the Internet. The most commonplace type of “denial of service” (DoS) attack is the TCP synchronization (SYN) flood. A SYN flood operates by falsifying an unusually large number of TCP connections to an Internet server. Those clients which initiate the SYN flood quickly exhaust the inbound connection resources available to the Internet server, resulting in the inability of the Internet server to accept valid connections from legitimate clients.
TCP-based communications between two different network entities initially can be established through the well-known three-way handshake. In the TCP three-way handshake, a client initially can request a TCP connection by transmitting a SYN packet to the intended server. The initial SYN packet can contain the IP address of the client and an initial packet sequence number determined solely by the client. The server can receive the SYN packet and can respond to the specified IP address with a combined acknowledgment (ACK) and SYN packet. This SYN/ACK packet can contain an acknowledgment of the client's selected initial packet sequence number in addition to an initial packet sequence number determined solely by the server. Finally, the client can acknowledge the initial packet sequence number selected by the server by transmitting to the server an ACK packet containing both the client and server selected initial packet sequence numbers. As will be apparent to one skilled in the art, the final ACK packet contains all state information necessary to establish a TCP connection. Notwithstanding, in a conventional TCP three-way handshake, the server can allocate internal resources for tracking the state information of the connection upon receipt of the initial SYN packet.
In a conventional DoS SYN flood attack, a malicious hacker can transmit multiple SYN requests containing spoofed IP addresses so that the target server exhausts internal resources allocating the state data for each maliciously transmitted SYN packet. The server cannot defend against such attacks inasmuch as the server cannot always distinguish between legitimate and illegitimate IP addresses contained in SYN packets. Furthermore, the server becomes paralyzed and cannot accept new TCP connections because its resources have become hopelessly consumed in consequence of the receipt of the malicious SYN packets.
In an effort to address the challenges associated with DoS SYN flood attacks, D. J. Bernstein developed a modified three-way handshake based upon what Bernstein referred to as a “SYN cookie”. A SYN cookie is a particular choice of an initial TCP packet sequence number selected by the server. In a typical SYN cookie, the five most significant bits are determined according to the equation, t mod 32, wherein the variable t is a thirty-two bit time counter which increments every sixty-four seconds. Notably, the next three bits represent the encoding of the TCP Maximum Segment Size (MSS) parameter. Finally, the least significant twenty-four bits represent a server-selected hash of the requesting client's IP address and port number, the server IP address and port number, and the variable t.
In the Bernstein method, the state of a requested TCP connection need not be stored upon receipt of the initial SYN packet. Rather, the required state information can be reproduced based upon an inspection of the finally received ACK packet transmitted by the requesting client. Hence, resources need not be allocated in the server until the conclusion of the three-way handshake. Moreover, the SYN cookie can be used to authenticate the requesting client by comparing the client IP address in the ACK packet with the IP address encoded in the SYN cookie. In consequence, the Bernstein method can be used to immunize a server from a DoS SYN flood attack. Notwithstanding, the Bernstein method is deficient in that the composition of the SYN cookie restricts the range of values for the MSS parameter.
Despite the advantages of the straight-forward application of SYN cookies, malicious hackers have been able to circumvent the protection afforded by SYN cookies. For instance, the composition of the SYN cookie permits the casual observer to decrypt the hash merely by observing a small sampling of valid traffic between the server and its clients. To address the inherent deficiencies in the Bernstein method, Steve Gibson improved upon the Bernstein method in his Genesis technology developed in January of 2001.
To address the vulnerability of the SYN cookie, in Genesis encrypted tokens are used in lieu of SYN cookies, though state information still is not stored until the final receipt of the ACK packet. Genesis, however, lacks support for client specified TCP parameters. Accordingly, in the Genesis scheme, communications sessions operate at the lowest common denominator of supported communications parameters including the smallest selected MSS value. In consequence, the use of the Genesis scheme can inhibit the performance of TCP communications between clients and servers. In fact, where large segment sizes are required to provide enhanced throughput for bulk data transfers, the performance can be even worse.
Significantly, both the Bernstein and Gibson methods are known to be ineffective where a malicious hacker installs a zombie process in a target server which permits one to bypass the TCP three-way handshake and communicate directly with the network device drivers through a raw sockets interface. This type of hacking attack has been referred to as a “quasi-TCP” attack. Though many firewalls perform packet inspection and packet filtering, packet inspection and filtering typically occur only during the setup of the TCP connection. Subsequent packets are assumed to be “safe”. Of course, where the TCP three-way handshake has been bypassed, as in the case of a quasi-TCP attach, this is a poor assumption. Accordingly, what is needed is a more effective method of combating DoS flood and quasi-TCP attacks.